Sip header to indicate mobility transfer operation

ABSTRACT

A method ( 500 ) of indicating a process to be implemented in support of a mobility transfer operation and a method ( 600 ) of responding to a mobility transfer operation being initiated. A session initiation protocol (SIP) request ( 120, 124, 128, 220, 226, 228 ) can be generated. The SIP request can indicate a mobility transfer type that corresponds to the mobility transfer operation. The SIP request can be sent from a first device ( 102, 106 ) participating in the mobility transfer operation to at least a second device ( 106, 102 ) participating in the mobility transfer operation.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.12/935,144, filed Sep. 28, 2010, which is the U.S. National PhaseApplication under 35 U.S.C. §371 of International Patent Application No.PCT/US2009/038058, filed Mar. 24, 2009, which claims the benefit ofEuropean Patent Application No. 08386004.9, filed Mar. 31, 2008, whichare hereby incorporated by reference herein in their entireties.

FIELD OF THE INVENTION

The present invention generally relates to mobile communications and,more particularly, to mobile communication protocols.

BACKGROUND OF THE INVENTION

Session Initiation Protocol (SIP) is an application-layer signalingprotocol for creating, modifying, and terminating communication sessionswith one or more participants. SIP operates independently from anunderlying transport layer, and thus can be used with a variety oftransport protocols. As such, SIP has gained wide acceptance in recentyears and now is commonly used in a variety of communication systems,including those that support mobile communications.

In a typical mobile communication scenario, for example when a mobilecommunication device (mobile device) is moving while being used, themobile device may roam from an area serviced by a first communicationnetwork (first network) that is SIP based to an area serviced by asecond communication network (second network) that is also SIP based oris circuit-switched (CS). When this occurs during a call, a newcommunication segment needs to be established in the second networkbefore the original communication segment with the first network isreleased.

The release of the original communication segment is typically initiatedby communicating a notification to the mobile device via the firstnetwork to indicate to the mobile device that the original communicationsegment is being released. Unfortunately, if the mobile device losesconnectivity to the first network before receiving such notification,the mobile device cannot immediately release the original communicationsegment in a conventional manner. An attempt to do so may be interpretedby the communication network as a release of the communication session.

SUMMARY OF THE INVENTION

The present invention relates to a method of indicating a process to beimplemented in support of a mobility transfer operation. The method caninclude generating a session initiation protocol (SIP) request thatindicates a mobility transfer type that corresponds to the mobilitytransfer operation. The SIP request can be generated in response todetecting that the mobility transfer operation has been initiated. TheSIP request can be sent from a first device participating in themobility transfer operation to at least a second device participating inthe mobility transfer operation.

Another aspect of the inventive arrangements relates to a method ofresponding to a mobility transfer operation being initiated. Such methodcan include receiving from a device participating in the mobilitytransfer operation a SIP request that indicates a mobility transfer typethat corresponds to the mobility transfer operation. Further, a processthat corresponds to the mobility transfer type can be identified, andthe identified process can be implemented.

The present invention also relates to a communication device thatparticipates in a mobility transfer operation. The communication devicecan include a processor that, responsive to detecting that the mobilitytransfer operation has been initiated, generates a SIP request thatindicates a mobility transfer type that corresponds to the mobilitytransfer operation. The communication device also can include acommunication adapter that sends the SIP request to at least a seconddevice participating in the mobility transfer operation.

Another aspect of the inventive arrangements relates to a communicationdevice participating in a mobility transfer operation. The communicationdevice can include a communication adapter that receives from a seconddevice participating in the mobility transfer operation a SIP requestthat indicates a mobility transfer type that corresponds to the mobilitytransfer operation. The communication device also can include aprocessor that identifies a process that corresponds to the mobilitytransfer type and implements the identified process.

BRIEF DESCRIPTION OF THE DRAWINGS

Preferred embodiments of the present invention will be described belowin more detail, with reference to the accompanying drawings, in which:

FIG. 1 depicts a communication system that is useful for understandingthe present invention;

FIG. 2 depicts another communication system that is useful forunderstanding the present invention;

FIG. 3 is a block diagram of a mobility application server that isuseful for understanding the present invention;

FIG. 4 is a block diagram of a client device that is useful forunderstanding the present invention;

FIG. 5 is a flowchart presenting a method of supporting a mobilitytransfer operation, which is useful for understanding the presentinvention; and

FIG. 6 is a flowchart presenting a method of responding to a mobilitytransfer operation being initiated, which is useful for understandingthe present invention.

DETAILED DESCRIPTION

While the specification concludes with claims defining features of theinvention that are regarded as novel, it is believed that the inventionwill be better understood from a consideration of the description inconjunction with the drawings. As required, detailed embodiments of thepresent invention are disclosed herein; however, it is to be understoodthat the disclosed embodiments are merely exemplary of the invention,which can be embodied in various forms. Therefore, specific structuraland functional details disclosed herein are not to be interpreted aslimiting, but merely as a basis for the claims and as a representativebasis for teaching one skilled in the art to variously employ thepresent invention in virtually any appropriately detailed structure.Further, the terms and phrases used herein are not intended to belimiting but rather to provide an understandable description of theinvention.

Arrangements described herein relate to the use of session initiationprotocol (SIP) requests which are configured to improve the manner inwhich mobility transfer operations are performed, for example when aclient device roams from one communication network to another during acommunication session, or when an active communication session istransferred from one device to another. More particularly, an indicatorof a mobility transfer type can be included within a SIP request, forinstance within the header of a SIP request, to indicate the type ofmobility transfer operation being performed. A device receiving such aSIP request can select an appropriate action to be implemented based onthe mobility transfer type indicator.

FIG. 1 depicts a communication system 100 useful for understanding thepresent invention. Within the communication system 100, voice callcontinuity transfer and/or session mobility may be implemented. A voicecall continuity transfer is a transfer of a communication session from acommunication network administered under a first protocol to anothercommunication network administered under a different protocol. Withsession mobility, the same protocol is used to administer both thecommunication network from which the communication session istransferred and the communication network receiving the transfer.

The communication system 100 can be configured in accordance withapplicable communication and air interface standards. Examples of suchstandards include, but are not limited to, Institute of Electrical andElectronics Engineers (IEEE) 802 wireless communications, for example,802.11 and 802.16, standards proposed by the Open Mobile Alliance (OMA),the 3rd Generation Partnership Project (3GPP), and/or the 3rd GenerationPartnership Project 2 (3GPP2). The communications system 100 also canimplement any of a variety of communication protocols including, but notlimited to, GSM, TDMA, CDMA, WCDMA, OFDM, etc. Moreover, thecommunication system 100 can include any of a variety of suitable datalinks including, but not limited to, circuit-switched andpacket-switched data links. Modifications or deviations from thestandards and/or protocols can be made to suitably implement the presentinvention.

The communication system 100 also can include a client device 102, whichcan be any mobile communication device suitably configured tocommunicate messages in accordance with SIP. Examples of such mobilecommunication devices include, but are not limited to, a mobiletelephone, a mobile radio, a personal digital assistant, a mobilecomputer, a mobile station, or the like. In that regard, the clientdevice 102 can communicate via wired and/or wireless communications.

The client device 102 can be associated with a home communicationnetwork 104, which may include a mobility application server 106 thatmanages mobility operations for the client device 102. For instance, themobility application server 106 can manage packet-switched topacket-switched mobility operations, as well as circuit-switched topacket-switched operations. The mobility application server 106 also mayserve as a communication session anchor point for the client device 102.

A SIP proxy server 108 also can be provided for the home communicationnetwork 104 to provide internet protocol (IP) registration and callsetup on behalf of the client device 102. Moreover, the SIP proxy server108 can intercept certain messages, such as SIP requests that include aheader that indicates the mobility transfer type, as will be describedherein. The functionality of the mobility application server 106 and/orthe SIP proxy server 108 can be implemented in a single processingdevice, or implemented among two or more processing devices.

The home communication network 104 may be communicatively linked to aplurality of other communication networks 110, 112, 114. One or more ofthe communication networks 110, 112, 114 can be radio access networks,packet-switched networks, circuit-switched networks, or the like. Forexample, each of the communication networks 110, 112, 114 can be radioaccess networks. Alternatively, a public switched telephone network(PSTN), an integrated services digital network (ISDN) and/or a fiberdistributed data interface (FDDI) can be implemented in lieu of one ormore of the communication networks 110, 112, 114. Moreover, any numberof intermediary networks may be implemented to support communicationbetween the home communication network 104 and the communicationnetworks 110, 112, 114. For example, the home communication network 104can be communicatively linked to the communication networks 110, 112,114 via the Internet, one or more backbones, a PSTN, an ISDN, a FDDI, orthe like.

In an initial operation state, a communication session can beestablished between the client device 102 and another communicationdevice 116. The communication session can be supported via a firstcommunication segment 118 established between the client device 102 andthe home communication network 104 via the communication network 110.The communication network 110 can be a communication network with whichthe client device 102 has established a SIP dialog. All messagescommunicated to and from the client device 102 in the communicationsession can be routed via the SIP proxy server 108, as is known to thoseskilled in the art.

As used herein, a “communication segment” is a communication signalingpath of a communication session that is established between a clientdevice and a mobility application server 106. In that regard, acommunication segment can comprise a contiguous sequence of one or moreSIP dialogs and/or circuit-switched connections. As used herein, a SIPdialog is a peer-to-peer relationship between two user agents, forexample a user agent of the client device 102 and a user agent of themobility application server 106. If there are other application servers(not shown) within the home communication network 104 that are linkedinto the communication segment 118, then the communication segment 118may include a sequence of dialogs.

During the communication session, the communication device 116 may becommunicatively linked to the client device's home communication network104, and thus to the client device 102, via the communication network114. Alternatively, the communication device 116 can be directly linkedto the home communication network 104, linked via the communicationnetwork 110 or the communication network 112, or linked to the homecommunication network 104 in any other suitable manner.

At some point during the communication session, the client device 102may roam from the communication network 110 to another communicationnetwork 112. Such roaming can be in response to the client device 102being physically moved, a user input, discovery of the communicationnetwork 112, or for any other suitable reason. To establish presence onthe communication network 112, the client device 102 can generate a SIPINVITE request 120 that includes a header comprising an indicator of amobility transfer type, for instance as a private header or as anothertype of header which can be configured to indicate a mobility transfertype. Optionally, the SIP INVITE request 120 also can include one ormore information parameters, for instance within a body of the SIPINVITE request 120. The information parameters can describecharacteristics of a second communication segment 122 to be establishedbetween the client device 102 and the home communication network 104 viathe communication network 112. The client device 102 can receive suchinformation from the communication network 112, for instance in anadvertisement generated by the communication network 112.

By way of example, if both the first communication network 110 and thesecond communication network 112 are administered using the sameprotocol, for instance each of the communication networks 110, 112 arepacket-switched networks, the indicator can be a session mobilityindicator. The session mobility indicator can indicate that the clientdevice 102 is handing off from a first communication network to a secondsimilarly configured communication network.

In contrast, if the first communication network 110 and the secondcommunication network 112 implement differing communication protocols,for instance one of the communication networks 110, 112 is apacket-switched network and the other is a circuit-switched network, theindicator can be a voice call continuity transfer indicator. The voicecall continuity transfer indicator can indicate that the client device102 is transferring from a first communication network administeredunder a first protocol to a second communication network administeredunder a different protocol.

The mobility transfer type indicator can be presented in the header inany suitable manner. For instance, one or more alphanumeric charactersthat are unique or that represent a unique sequence can be used as aparameter to represent each mobility transfer type. In example, thenumeral “1” can be assigned as a parameter that indicates a sessionmobility, and the numeral “2” can be assigned as a parameter thatindicates a voice call continuity transfer. Similarly, the numeral “3”can be assigned as a parameter that indicates an inter-device transfer,which will be described in further detail with reference to FIG. 2.Nonetheless, any other indicators can be used and the invention is notlimited in this regard.

An example of a header that includes a mobility transfer type indicatormay be represented as follows:

-   -   P-Mobility: transfer; cause=1; text=“Voice Call Continuity        Transfer”        In this example, the parameter “P-Mobility” can indicate that        the header is a private header named “P-Mobility,” the parameter        “transfer” can be a header value that indicates that the SIP        request to which the header corresponds was generated as part of        a transfer process, and the term “cause=1” can indicate that the        mobility transfer type indicator is represented by the parameter        “1.” The term “text”=‘Voice call continuity transfer’ optionally        may be included to provide descriptive text corresponding to the        mobility transfer type indicator.

Another example header that includes a mobility transfer type indicatormay be represented as follows:

-   -   P-Mobility: transfer; cause=2, transfer; cause=3;        text=“Inter-Device Session Mobility Transfer”        In this example, the mobility transfer type indicator is        represented by the terms “2” and “3,” for instance to indicate        an inter-device session mobility transfer.

The SIP INVITE request 120 can be sent from the client device 102 viathe second communication segment 122 established between the clientdevice 102 and the home communication network 104 via the communicationnetwork 112. The SIP INVITE request 120 can be addressed to thecommunication device 116 or to the home communication network 104. Ifthe SIP INVITE request 120 is addressed to the communication device 116,the address of the mobility application server 106 need not be indicatedwithin the SIP INVITE request 120 because, regardless where the SIPINVITE request 120 is sent, the SIP proxy server 108 can intercept theSIP INVITE request 120 and forward the SIP INVITE request 120 to themobility application server 106. For example, the SIP proxy server 108can include an algorithm that identifies SIP messages that have headersthat comprise a mobility transfer type indicator, and forward all suchmessages to the mobility application server 106. Suitable processesand/or queries can be used by the SIP proxy server 108 to identify themobility application server 106 based on a user subscription associatedwith the client device 102.

When, or sometime after, sending the SIP INVITE request 120, the clientdevice 102 also can generate a SIP BYE request 124 that also includesthe mobility transfer type indicator. The client device 102 then cansend the SIP BYE request 124 via the communication segment 118 totrigger release of the communication segment 118. The SIP BYE request124 can be addressed to the communication device 116 or to the homecommunication network 104.

In response to receiving the SIP INVITE request 120, the mobilityapplication server 106 can determine whether the SIP INVITE request 120comprises a mobility transfer type indicator. Presence of the mobilitytransfer type indicator can indicate to the mobility application server106 that a mobility transfer operation is taking place with anestablished communication session with which the SIP INVITE request 120is associated, and thus to establish the second communication segment122 as a new communication segment for the communication session inwhich the SIP INVITE request 120 is associated.

In addition, if the SIP INVITE request 120 includes the mobilitytransfer type indicator, the mobility application server 106 cangenerate a SIP re-INVITE request 126 and send the SIP re-INVITE request126 to the communication device 116. The SIP re-INVITE request 126 canidentify at least one characteristic associated with a secondcommunication segment 122 that is different than a correspondingcharacteristic associated with the first communication segment 118. Suchcharacteristic can be based on information about the communicationnetwork 112 received in the SIP INVITE request 120, or based oninformation otherwise conveyed to the mobility application server 106.Other information pertaining to the communication session also may beincluded in the SIP re-INVITE request 126.

If the mobility application server 106 also receives the SIP BYE request124 generated by the client device 102 and communicated via thecommunication segment 118, the mobility application server 106 need notgenerate its own SIP BYE request to release the communication segment118. Moreover, if the SIP INVITE request 120 does not include themobility transfer type indicator, the mobility application server 106need not generate a SIP BYE request since a transfer of thecommunication session is not being indicated within the SIP INVITErequest 120.

If, however, the mobility application server 106 does not receive theSIP BYE request 124 when the SIP INVITE request 120 is received, orimmediately thereafter, and the SIP INVITE request 120 does include amobility type indicator, the mobility application server 106 can parsethe mobility transfer type indicator from the SIP INVITE request 120 andgenerate a SIP BYE request 128. The SIP BYE request 128 can include aheader comprising the mobility transfer type indicator, for instance asa private header, as a reason header or as another type of header whichcan be configured to indicate a mobility transfer. The mobilityapplication server 106 can send the SIP BYE request 128 to the clientdevice 102 via the first communication segment 118 established via thecommunication network 110, which can trigger the mobility applicationserver 106 to release the first communication segment 118.

If the client device 102 receives the SIP BYE request 128 and determinesthat the SIP BYE request 128 is associated with the communicationsession for which the SIP INVITE request 120 was associated, but theclient device has already sent the SIP BYE request 124, the clientdevice 102 need not perform any further processing of the SIP BYErequest 128. If, however, the client device 102 has not yet sent the SIPBYE request 124, receipt of the SIP BYE request 128 can indicate to theclient device 102 that the SIP BYE request 124 may no longer be neededto release the communication segment 118.

Similarly, if the mobility application server 106 receives the SIP BYErequest 124 and determines that the SIP BYE request 124 is associatedwith the communication session with which the SIP INVITE request 120 wasassociated, the mobility application server 106 can determine whetherthe SIP BYE request 124 includes a mobility transfer type indicator. Ifthe mobility application server 106 identifies a mobility type transferindicator within the SIP BYE request 124, the mobility applicationserver 106 can determine that the SIP BYE request 124 is beingcommunicated to release the communication segment 118 rather than to endthe communication session, and thus take no further action in responseto the SIP BYE request 124.

If, however, the mobility application server 106 receives from theclient device 102 a SIP BYE request that does not include a mobilitytype transfer indicator, the mobility application server 106 caninterpret such SIP BYE request as a request from the client device 102to terminate the communication session. In response, the mobilityapplication server 106 can terminate the communication session byreleasing all communication segments supporting the communicationsession.

Notably, the ability of the client device 102 to send the SIP BYErequest 124 when the SIP BYE request 128 is not received enables theclient device 102 to efficiently release the first communication segment118, even when communication with the communication network 110 is lost.Moreover, the inclusion of the mobility transfer type indicator withinthe SIP BYE request 124 can prevent the mobility application server 106from releasing one or more other communication segments that may be inuse in the communication session.

FIG. 2 depicts a communication system 200 useful for understandingarrangements in which an inter-device transfer may be implemented. Aninter-device transfer is the transfer of a communication session from afirst client device to a second client device. In one arrangement, aninter-device transfer can be implemented in addition to a voice callcontinuity transfer or session mobility.

The communication system 200 can include the client device 102, the homecommunication network 104, the mobility application server 106, the SIPproxy server 108, and the communication networks 110, 114. Optionally,the communication system 200 also can include the communication network112. In addition, the communication system 200 can comprise a clientdevice 230. The client device 230 can be a mobile communication device,or may be a communication device that is not typically mobile. Forexample, the client device 230 can be a computer, a telephone, anaudio/video system, or the like. The client device 230 can becommunicatively linked to the home communication network 104 via thecommunication network 112. Alternatively, the client device 230 can becommunicatively linked to the home communication network 104 via thecommunication network 110, the communication network 114, or linked inany other suitable manner.

In an initial operation state, a communication session can beestablished between the client device 102 and another communicationdevice 116. The communication session can be supported via a firstcommunication segment 218 established between the client device 102 andthe home communication network 104 via the communication network 110.

At some point during the communication session, a determination can bemade to perform an inter-device transfer of the communication session tothe client device 230. Such transfer can be initiated in response to auser command entered into the client device 102 and/or the client device230, in response to detection of the client device 102 being inproximity to the client device 230, or vice versa, or in response to anyother applicable circumstances.

When the inter-device transfer is initiated, the client device 230 cansend a SIP INVITE request 220 via a second communication segment 222established between the client device 230 and the home communicationnetwork 104 via the communication network 112 (or another communicationnetwork with which the client device 230 is communicatively linked). TheSIP INVITE request 220 can include a mobility transfer type indicator,which can indicate that an inter-device transfer is taking place.

In addition, the mobility transfer type indicator can indicate a voicecall continuity transfer or session mobility, if applicable, that isbeing implemented as part of the inter-device transfer process. Forinstance, if the communication networks 110, 112 both are administeredunder the same protocol, the mobility transfer type indicator canindicate that both inter-device transfer and session mobility are takingplace. If the communication networks 110, 112 are administered underdifferent protocols, the mobility transfer type indicator can indicatethat inter-device transfer and voice call continuity transfer are takingplace.

If the SIP INVITE request 220 is addressed to the communication device116, the address of the mobility application server 104 need not beindicated within the SIP INVITE request 220 since the SIP INVITE request220 can be intercepted by the SIP proxy server 108 and forwarded to themobility application server 106, as previously described. The mobilityapplication server 106 can determine whether the SIP INVITE request 220comprises a mobility transfer type indicator and, if so, establish thesecond communication segment 222 as a new communication segment for thecommunication session for which the SIP INVITE request 220 was sent. Themobility application server 106 also can release one or more previouscommunication segments associated with the communication session, suchas the first communication segment 218.

In addition, the mobility application server 106 can generate a SIPre-INVITE request 224 and send the SIP re-INVITE request 224 to thecommunication device 116. The mobility application server 106 also cangenerate a SIP BYE request 226 comprising the mobility type indicatorand send the SIP BYE request 226 to the client device 102. The SIPre-INVITE request 224 and the SIP BYE request 226 can be generated, sentand processed by the various system components as previously describedfor the SIP re-INVITE request 126 and the SIP BYE request 128 of FIG. 1.

For example, the client device 102 can determine whether the SIP BYErequest 226 includes a mobility transfer type indicator. If so, theclient device 102 need not take any further action to release the firstcommunication segment 218. In some circumstances the client device 102may not receive the SIP BYE request 226, but can be configured to sendthe SIP BYE request 228 in response to a particular event. For example,the client device 102 can generate and send the SIP BYE request 228 inresponse to a user action taken on the client device's user interface,after detecting that a period of time has elapsed since detecting theclient device 230, or based upon any other suitable event.

FIG. 3 is a block diagram depicting one example of the mobilityapplication server 106 that is useful for understanding the presentinvention. The mobility application server 106 can include a processor302, which may comprise, for example, one or more central processingunits (CPUs), one or more digital signal processors (DSPs), one or moreapplication specific integrated circuits (ASICs), one or moreprogrammable logic devices (PLDs), a plurality of discrete componentsthat can cooperate to process data, and/or any other suitable processingdevice. In an arrangement in which a plurality of such components areprovided, the components can be coupled together to perform variousprocessing functions as described herein.

The mobility application server 106 also can include, or be coupled to,a communication adapter 304. The communication adapter 304 can be anydata send/receive device that is suitable for communicating via acommunications network. For example, the communication adapter 304 canbe a transceiver that is configured to wirelessly communicate via a basetransceiver station, a repeater, an access point, or any other suitablewireless network device. In another arrangement, the communicationadapter 304 can be a wired communication port or a network adapterconfigured to communicate via wired communication, for instance via aswitch or a router. The communication adapter 304 can communicate datavia GSM, TDMA, CDMA, WCDMA, OFDM, direct wireless communication, TCP/IPand/or any other suitable communication protocols.

The mobility application server 106 further can include data storage306. The data storage 306 can include one or more storage devices, eachof which may include, but is not limited to, a magnetic storage medium,an electronic storage medium, an optical storage medium, amagneto-optical storage medium, and/or any other storage medium suitablefor storing digital information. In one arrangement, the data storage306 can be integrated into the processor 302, though this need not bethe case.

At least one mobility application 308 can be stored on the data storage306 or otherwise made accessible to the processor 302. The mobilityapplication 308 can be executed by the processor 302 to implement themethods and processes described herein that are performed by themobility application server 106. For example, the processor 302 canexecute the mobility application 308 to send and receive SIP requestsvia the communication adapter 304, process received SIP requests todetermine whether such requests comprise mobility transfer typeindicators, generate SIP requests in response to such determinations,some of which may include mobility transfer type indicators, and so on.The mobility application 308 also can be executed to perform any othermobility functions, and the invention is not limited in this regard.

FIG. 4 is a block diagram of an example of a client device 400 that isuseful for understanding the present invention. The client device 400depicted can be implemented as the client device 102 of FIGS. 1-2 and/orthe client device 230 of FIG. 2. The client device 400 can include aprocessor 402, which may comprise, for example, one or more CPUs, one ormore DSPs, one or more ASICs, one or more PLDs, a plurality of discretecomponents that can cooperate to process data, and/or any other suitableprocessing device. As noted, in an arrangement in which a plurality ofsuch components are provided, the components can be coupled together toperform various processing functions as described herein.

The client device 400 also can include a communication adapter 404 and adata storage 406. The communication adapter 404 can be any datasend/receive device that is suitable for communicating via a wiredand/or wireless communications network and the data storage 408 caninclude one or more storage devices, for example as previously describedwith respect to FIG. 3.

A user interface 408 also can be included with the client device 400.The user interface can include one or more keys, soft keys, keyboards,buttons, displays, touch screens, indicator lamps, input audiotransducers, output audio transducers, pointing devices, haptic devices,or the like. The user interface 408 can receive user inputs and presentinformation to a user in any of a variety of suitable formats.

At least one client application 410 can be stored on the data storage406 or otherwise made accessible to the processor 402. The clientapplication 410 can be executed by the processor 402 to implement themethods and processes described herein that are performed by one or moreof the client devices. For example, the processor 402 can execute theclient application 410 to send and receive SIP requests via thecommunication adapter 404, process received SIP requests to determinewhether such requests comprise mobility transfer type indicators,generate SIP requests in response to such determinations, some of whichmay include mobility transfer type indicators, and so on. The clientapplication 410 also can be executed to perform any other client devicefunctions, and the invention is not limited in this regard.

FIG. 5 is a flowchart presenting a method 500 of supporting a mobilitytransfer operation. At step 502, a mobility transfer operation that hasbeen initiated can be detected. For example, the mobility transferoperation can be detected on the client device by detecting a decisionby the client device to proceed with a mobility transfer. In anotherexample, the mobility application server can detect that a mobilitytransfer operation has been initiated by receiving from the clientdevice a SIP INVITE request comprising a mobility transfer typeindicator. Still, initiation of the mobility transfer operation can bedetected in any other suitable manner and the invention is not limitedto these examples.

At step 504, a SIP request can be generated that indicates a mobilitytransfer type that corresponds to the mobility transfer operation. Forexample, the SIP request can be a SIP INVITE request generated by theclient device, and can include a header which includes a mobilitytransfer type indicator that indicates the type of mobility transferoperation that is being implemented. In another example, the SIP requestcan be a SIP BYE request generated by the mobility application server,which also can include a header that includes a mobility transfer typeindicator. The mobility application server can receive the mobilitytransfer type indicator from the client device in a SIP INVITE request.

The mobility transfer type indicator can indicate a voice callcontinuity transfer, a session mobility transfer, an inter-devicetransfer, and/or any other type of transfer that is being implemented.As noted, the mobility transfer type indicator can identify one or moretypes of mobility transfer being implemented.

Optionally, the SIP request that is generated by the client device orthe mobility application server can comprise at least one informationparameter in a body of the SIP request. The information parameter candescribe characteristics of the second communication segment to which acommunication session is being transferred from a first communicationsegment.

At step 506, the generated SIP request can be sent from a first deviceparticipating in the mobility transfer operation to at least a seconddevice participating in the mobility transfer operation. For example,the client device can send the generated SIP INVITE request to themobility application server, or the mobility application server can sendthe generated SIP BYE request to the client device.

FIG. 6 is a flowchart presenting a method 600 of responding to amobility transfer operation being initiated. At step 602, a SIP requestcan be received from a device participating in a mobility transferoperation. The SIP request can indicate a mobility transfer type thatcorresponds to the mobility transfer operation. The SIP request can be,for example, a SIP INVITE request or a SIP BYE request generated by aclient device, and such SIP request can include a header that indicatesthe mobility transfer type. The SIP request generated by the clientdevice can be received by the mobility application server.

In another example, the SIP request can be a SIP BYE request generatedby the mobility application server, and such SIP BYE request can includea header that indicates the mobility transfer type. Such SIP BYE requestcan be received by the client device.

In one arrangement, the SIP request can include one or more informationparameters in a body of the SIP request. As noted, such parameters candescribe a characteristic of the second communication segment to which acommunication session is being transferred from the first communicationsegment.

At step 604, a process that corresponds to the mobility transfer typecan be identified. At step 606, the identified process can beimplemented. For instance, if the SIP request is a SIP INVITE requestgenerated by the client device, the mobility application server canestablish a second communication segment between the client device andthe mobility application server in order to maintain a communicationsession being transferred to the second communication segment from afirst communication segment. The mobility application server also cangenerate a SIP BYE request that includes a header that indicates themobility transfer type, and send the SIP BYE request via the firstcommunication segment to the client device and/or a second clientdevice. Further, the mobility application server can generate a SIPre-INVITE request that may identify at least one characteristicassociated with a second communication segment that is different than acorresponding characteristic associated with the first communicationsegment. The mobility application server then can send the SIP re-INVITErequest to at least one communication device with which the clientdevice is communicating during the communication session.

In an example in which the SIP request is a SIP BYE request generated bythe client device, the mobility application server can release the firstcommunication segment. Similarly, if the SIP request is a SIP BYErequest generated by the mobility application server, the client devicecan release the first communication segment.

The flowchart and block diagrams in the figures illustrate thearchitecture, functionality, and operation of possible implementationsof systems, methods and computer program products according to variousembodiments of the present invention. In this regard, each block in theflowchart or block diagrams may represent a module, segment, or portionof code, which comprises one or more executable instructions forimplementing the specified logical function(s). It should also be notedthat, in some alternative implementations, the functions noted in theblock may occur out of the order noted in the figures. For example, twoblocks shown in succession may, in fact, be executed substantiallyconcurrently, or the blocks may sometimes be executed in the reverseorder, depending upon the functionality involved.

The present invention can be realized in hardware, software, or acombination of hardware and software. The present invention can berealized in a centralized fashion in one processing system or in adistributed fashion where different elements are spread across severalinterconnected processing systems. Any kind of processing system orother apparatus adapted for carrying out the methods described herein issuited. A typical combination of hardware and software can be aprocessing system with an application that, when being loaded andexecuted, controls the processing system such that it carries out themethods described herein. The present invention also can be embedded ina program storage device readable by a machine, tangibly embodying aprogram of instructions executable by the machine to perform methods andprocesses described herein. The present invention also can be embeddedin an application product which comprises all the features enabling theimplementation of the methods described herein and, which when loaded ina processing system, is able to carry out these methods.

The term “application,” as well as variants thereof, in the presentcontext, mean any expression, in any language, code or notation, of aset of instructions intended to cause a system having an informationprocessing capability to perform a particular function either directlyor after either or both of the following: a) conversion to anotherlanguage, code or notation; b) reproduction in a different materialform. For example, an application can include, but is not limited to, ascript, a subroutine, a function, a procedure, an object method, anobject implementation, an executable application, an applet, a servlet,a MIDlet, a source code, an object code, a shared library/dynamic loadlibrary and/or other sequence of instructions designed for execution ona processing system.

The terms “a” and “an,” as used herein, are defined as one or more thanone. The term “plurality,” as used herein, is defined as two or morethan two. The term “another,” as used herein, is defined as at least asecond or more. The terms “including” and/or “having,” as used herein,are defined as comprising (i.e. open language).

This invention can be embodied in other forms without departing from thespirit or essential attributes thereof. Accordingly, reference should bemade to the following claims, rather than to the foregoingspecification, as indicating the scope of the invention.

What is claimed is:
 1. A method of indicating a process to beimplemented in support of mobility transfer operations, comprising:responsive to detecting that a mobility transfer operation has beeninitiated where a client device has roamed from a first communicationnetwork to a second communication network during a communicationsession, generating a session initiation protocol (SIP) request thatindicates a mobility transfer type from a plurality of mobility transfertypes that corresponds to the mobility transfer operation beingperformed; and sending the SIP request from the client deviceparticipating in the mobility transfer operation in order to maintainthe communication session being transferred to the second communicationsegment from the first communication segment.
 2. The method of claim 1,wherein generating the SIP request comprises generating a SIP INVITErequest comprising a header that indicates the mobility transfer type.3. The method of claim 1, wherein generating the SIP request comprisesgenerating a SIP BYE request comprising a header that indicates themobility transfer type.
 4. The method of claim 1, wherein the SIPrequest includes a mobility transfer type indicator in a header of theSIP request.
 5. The method of claim 4, wherein the mobility transfertype indicator is selected from one or more characters and wherein eachof the one or more characters indicates the mobility transfer operationselected from a group consisting of a voice call continuity transfer, asession mobility transfer, and an inter-device transfer.
 6. The methodof claim 4, wherein the mobility transfer type indicator is a sequenceof characters and wherein the sequence of characters indicates themobility transfer operation selected from a group consisting of a voicecall continuity transfer, a session mobility transfer, and aninter-device transfer.
 7. The method of claim 1, wherein the SIP requestincludes at least one information parameter in the SIP request thatdescribes a characteristic of a second communication segment establishedvia the second communication network that is different than acorresponding characteristic of a first communication segmentestablished via the first communication network.
 8. The method of claim7, wherein the at least one information parameter is included in a bodyof the SIP request.
 9. The method of claim 1, wherein the SIP request issent to at least a home communication network that includes a mobilityapplication server to request that the second communication segment beestablished between the client device and the mobility applicationserver.
 10. A communication device participating in mobility transferoperations, comprising: a processor that, responsive to detecting that amobility transfer operation has been initiated where the communicationdevice has roamed from a first communication network to a secondcommunication network during a communication session, generates asession initiation protocol (SIP) request that indicates a mobilitytransfer type from a plurality of mobility transfer types thatcorresponds to the mobility transfer operation being performed; and acommunication adapter that sends the SIP request from the communicationdevice participating in the mobility transfer operation in order tomaintain the communication session being transferred to the secondcommunication segment from the first communication segment.
 11. Thecommunication device of claim 10, wherein the communication device is aclient device and wherein the SIP request is a SIP INVITE requestcomprising a header that indicates the mobility transfer type.
 12. Thecommunication device of claim 10, wherein the communication device is aclient device and wherein the SIP request is a SIP BYE requestcomprising a header that indicates the mobility transfer type.
 13. Thecommunication device of claim 10, wherein the SIP request includes amobile transfer type indicator in a header of the SIP request.
 14. Thecommunication device of claim 13, wherein the mobility transfer typeindicator is selected from one or more characters and wherein each ofthe one or more characters indicates the mobility transfer operationselected from a group consisting of a voice call continuity transfer, asession mobility transfer, and an inter-device transfer.
 15. Thecommunication device of claim 13, wherein the mobility transfer typeindicator is a sequence of characters and wherein the sequence ofcharacters indicates the mobility transfer operation selected from agroup consisting of a voice call continuity transfer, a session mobilitytransfer, and an inter-device transfer.
 16. The communication device ofclaim 10, wherein the SIP request includes at least one informationparameter in the SIP request that describes a characteristic of a secondcommunication segment established via the second communication networkthat is different than a corresponding characteristic of a firstcommunication segment established via the first communication network.17. The communication device of claim 16, wherein the at least oneinformation parameter is included in a body of the SIP request.
 18. Thecommunication device of claim 10, wherein the SIP request is sent to atleast a home communication network that includes a mobility applicationserver to request that the second communication segment be establishedbetween the communication device and the mobility application server.19. A non-transitory computer-readable medium containing computerexecutable instructions that, when executed by a processor, cause theprocessor to perform a method for supporting mobility transferoperations, the method comprising: responsive to detecting that amobility transfer operation has been initiated where a client device hasroamed from a first communication network to a second communicationnetwork during a communication session, generating a session initiationprotocol (SIP) request that indicates a mobility transfer type from aplurality of mobility transfer types that corresponds to the mobilitytransfer operation being performed; and sending the SIP request from theclient device participating in the mobility transfer operation in orderto maintain the communication session being transferred to the secondcommunication segment from the first communication segment.